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METHODS DESIGN FOR DEVELOPING AN AUTOMATIC 



DATA PROCESSING SYSTEM 



By 
Adolph Fo Moravec 



This paper describes the methods developed for designing 
a military tactical system which is to use advanced automatic data 
processing equipment in the Field Army. 

Background 

In late 19 5^ the Commanding General, United States Conti- 
nental Army Command (USCONARC), requested the support of the Office 
of the Chief Signal Officer in supplying advice and assistance to a 
USCONARC committee engaged in determining the feasibility of apply- 
ing automatic data processing (ADP) to tactical military operations. 
The Chief Signal Officer established the Signal Corps ADPS Technical 
Analysis Group. The United States Army Electronic Proving . Ground 
(USAEPG) at Fort Huachuca in Arizona .was a member of this group, a- 
long -with the participants from other Signal Corps agencies. This 
group considered approximately one hundred separate Army applications, 
as specified by the DA/USCONARC Committee, and as a result published, 
in February, 1957^ a seven -volume report which affirmed the feasibil- 
ity of tactical ADP applications, and recommended a program for fur- 
ther study 

Concurrently with the work of the technical analysis group, 
plans were made for developing militarized equipment which would be 
required for an ADP program. The Chief Signal Officer assigned to 
the U« S. Army Signal Research and Development Laboratories (USABRDL) 
the responsibility for developing a family of mobile, militarized 
computers (FIELDATA) and associated equipment. The Chief Signal 
Officer also assigned to USAEPG at Fort Huachuca the responsibility 
for the design of tactical ADP systems and the testing of these sys- 
tems under field conditions. The ADP Department at USAEPG has pro- 
ceeded with the establishment of an ADP test center and has initiated 
a program and plan for accomplishing the assigned USAEPG part of the 
Army Tactical ADP Program. 

To provide technical assistance in the implementation of its 
program, the Army Electronic Proving Ground at Fort Huachuca has en- 
gaged the services of several private contractors. As a prime con- 
tractor for technical assistance in the ADP program, USAEPG has a five^ 
year contract with Ramo-Wooldridge, a Division of Thompson Ramo 



Methods Design for Developing an Automatic Data Processing Systeiii --2 

¥ooldridge, Inc. Coordination, therefore, is required among the various 
organizations participating in the ADP program. These organizations are 
shown in Figure 1. 

Figure 1, Organization Chart, DA/USCONARC Tactical ADPS Pro- 
gram, indicates, graphically, the relationship and function which are 
provided by each member in the ABPS program. Integration of tactical 
ADP systems into the Field Army operations will take place under the 
direction of USCONARC, with the aid of the Airborne and Electronics 
Board during the qualification testing phase. 

Establishing the Work Effort 

Early in 1959 USCONARC approved the following four studies 
produced by the Artillery School at Fort Sill, Oklahoma: 

1. Unit Firing Capabilities 

2. Input /Output Data for Technical Fire Control 

3. Artillery Survey 

k. Tactical Ammunition Control 

These studies recommended that certain portions of the total tactical 
field artillery operation be automated using equipment designed by the 
Signal Corps. 

After detailed analysis of these studies, and after dis- 
cussions with the various agencies concerned with the objectives of 
the ADP program, it was decided to select the function of the field 
artillery as one of the first tactical application areas for auto- 
mation. This particular Automatic Data Processing System (ADPS) ap- 
plication area was designated as the Fire Support Subsystem 1 (SS-l) = 
¥ith enthusiastic and close cooperation of the study group, together 
with command level support from Fort Sill, it was decided to isolate 
a part of this subsystem and designate it as Subsystem la (SS-la) . 
The purpose of this action was to mechanize and field test this portion 
ahead of the complete subsystem (SS-l), and to demonstrate the capabil- 
ities of tactical ADP equipment to a user group at, the earliest possible 
date. 

At this point, the SS-la program was in existence and we now 
needed a plan for implementing it. Figure 2 indicates "the technical 
plan for developing . SS -la . In addition to this plan, an organization 
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■was established for carrying out the effort; more will he said ahout 
this area later in the paper. Since this technical plan represents 
the hackhone of the total effort, I will discuss each step in some 
detail. It should also he noted here that each step in the plan is 
associated with a special document which was designed for specific 
step development. 

Objectives and Definitions 

This first step establishes the general direction and 
functional areas to be automated. In effect, it is the planning 
framework for automating certain artillery procedures. A document 
reflecting this framework is prepared, coordinated, and approved by 
the ADP Chairman of the United States Army Artillery and Missile 
School (USAAMS), Fort Sill, Oklahoma, and the ADP Department, USAEPG, 
Fort Huachuca, Arizona, All future work efforts are then based upon 
this document. 

Figure 3 indicates the general contents of this document. 
After the objectives and definitions of SS-la had been approved, 
artillery operations and procedures were segregated into workable 
functional areas. These functional areas roughly corresponded with 
the division of responsibility of the various departments in the 
Artillery School at Fort Sill. (For example, the functional area of 
fire control is the responsibility of the Gunnery Department at Fort 
Sill) . 

Functional Design Charts 

The second step in developing this subsystem. is to detennine 
the general requirements for each functional area. These general re- 
quirements are supplied by each user department at the Artillery 
School. [The functional design chart represents the first documen- 
tation reflecting artillery procedures in a particular area of oper- 
ation. 

Figures ka. and 4b. represent a sample of the functional de- 
sign chart in the area of Firing Unit Capabilities. The charts include 
the following data: basic function, purpose, inputs -file -outputs, and 
remarks. Included is the user documentation reference for the pro- 
cedure involved. These charts are revised and updated as required. 
After completion of these forms a flow -of -data analysis is prepared by 
the systems analyst responsible for this area. 

Functional Area Analyses 

The flow-of-data analysis — the next step in the plan --is 
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developed in a document entitled Functional Area Analysis . The purpose 
of this analysis is to indicate the "when" and 'Vhere" of specific ele- 
ments of data. The instructional notes that follow indicate the detail 
and coordination required for a complete analysis. 

Instructional Notes 

A. -After functional design charts for each area are pre- 
pared, using the ohjective and definitions of SS-la 
as a general guide, functional area analysis is accom- 
plished by preparing the following: 

1. Input -File -Output Forms (See Figures 5, 6, 7) 

2. Functional Area Flow Chart (in detail) 

3. Unit Equipment Utilization Forms 

B» The functional area analysis must indicate the step -by - 
step flow of SS-la data, explaining in detail: 

1. Required inputs 

2. Required file contents and maintenance 

3. Required outputs 

k. Type of equipment involved in flow -of -data 

5. Frequency and sequence of data used 

6. Characters or words of storage required 

7. Security classification desired 

8. Required formats for all messages, codes, and doc- 
umentation 

9* Glossary of terms 

C. The analysis is completed and coordinated simultaneously 
by members of the working team. The analysis is cate- 
gorized as preliminary until the working team agrees 
that the analysis is satisfactorily completed. At this 
point, the analysis is characterized as firm. 
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D. Input -File -Output sheets and flow charts are refer- 
enced and sequenced "by name and sequence number vhich 
corresponds to the sequence number of the functional 
design chart. 

E. Input -File -Output sheets and flow charts for each 
functional area are updated, distributed, and filed 
in the operational "docket file" notebook. 

F. Unit equipment utilization forms are completed for 
each ADP unit equipment in the functional area. 



Functional Area Working Team Coordination ■* Preliminary - Firm 



Systems Analyst 

Date 
Programming Analyst 



Date 
Ft, Sill Project Officer 



Date 
Ft. Sill ADP Coordinator 



Date 

This analysis is composed of preparing a detailed flow chart 
and input -file -output forms. It is documents of this type that develop 
the subsystem in specific detail. After coordination with each individ- 
ual working team, this analysis provides valuable inf omiation such as 
(l) storage and memory re qxiirements, (2) volumes of data to be processed, 
(3) specific dissemination needs, {k) types of input /output formats, and 
(5) timing of data processing activities, to mention a few. It is at 
this point that the subsystem is described in step -by -step detail and 
both programming and equipment requirements can be effectively developed. 

It is also at this point where approved deviations are de- 
veloped between the present manual system and the new proposed ADP sys- 
tem. Studying Figures 5^ 6, and 7; it can be seen that in addition to 
the information required by the form, a running flow chart describing 
the flow -of -data for a particular input -file -output sequence is indi- 
cated in the remarks column. Included in functional area analysis docu- 
mentation is a glossary of terms peculiar to the area being analyzed. 

General Logical Flow Chart 

Iflien the Functional Area Analysis document for a particular 
area is considered firm, a general logical flow chart; is prepared out- 
lining the major steps and decision points of the functional operation. 



Ifethods Design for Developing an Automatic Data Processing System--6 



The flov chart presents the "what" data In the "which" sequence for com- 
pleting a functional operation at a specific echelon. Data flowing into 
this functional area from other areas are specified and sequenced in the 
operation as required. The same procedure applies for data leaving this 
functional area. Also, it presents a picture of the specific tasks re- 
quiring additional detailed flow charting and detailed explanations. It 
is this general flow chart that is used later for integrating the var- 
ious interlocking functional areas. 

Specific Task/Routine Flow Charts 

These particular flow charts fulfill the "how" requirement 
of a specific task within a general logical flow chart. It is this flow 
chart that passes to the programmer fpr his analysis and subsequent pro- 
gramming . 

Graphically, the concept is as follows*. 



Functional Area General 
Logical Flow Chart 
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This methodology, which might he called the "Function-Task -Routine -Method" 
has several advantages. 



1, System and programming analysis can he accomplished immed- 
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idately in those areas where the information and pro - 
cedures are firm and/or in those areas which may closely 
resemhle the original manual system. We have found, for 
instance, that in some cases we were continually revising 
the functional design charts (user requirements) to re - 
fleet improved operating procedures, while in other in- 
stances it was possible to "begin programming almost immed- 
iately. 

2. This method is not overly detailed to the extent of re- 
quiring elaborate bookkeeping procedures or complicated 
recording systems for keeping accountability for each and 
every piece of documentation. Individuals find it diffi- 
cult to keep in mind the whole picture and continuity of 
the entire effort if they are required to keep track of 
the status of many unrelated groups of information. And 
yet they are awed when presented the entire picture in a 
single complexity of detail. The "Function -Task -Routine 
Method" represents a logical compromise between extremes 
in method analysis. 

3. We have found that rapport between the systems analyst 
and the programming analyst is increased by using this 
method. It has sufficient detail for the programmer and 
yet it is flexible enough to embrace changes (small and 
large) to the system. 

k. And, of course, by segregating Subsystem la into functional 
areas resulted in judiciously utilizing, as needed, the 
time and manpower available. 

Specific Tasks to be Programmed 

This is a simple tabular listing or schedule of the specific 
tasks to be programmed in some order of priority. It should include a 
description of input routines, primary and subroutines, connecting 
routines, output routines, and special executive routines as required. 
In addition,, the names of the systems analyst and programmer should be 
indicated as well as an estimate of the manhours or mandays to complete 
the programming and systems effort. This docinnent pinpoints the priority 
and team assignments for accomplishing the efforts associated with each 
specific task or groups of tasks. It is at this point when management 
can obtain a reliable "fix" concerning the efforts required in the total 
program with respect to systems and programming analyses. 
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The Programming Effort 

The next step is the actual programming effort. This involves 
accomplishing programming analysis^ coding^ check-out, and debugging of 
the various programs. In this effort the programmer and systems analyst 
must keep in mind equipment capability, message format, and the volume 
of infoimation to be handled in the system. It is this step where flexi- 
bility and control are built into the system by efficiently preparing sub- 
routines and executive routines which can call for strategic data at the 
proper time, and which can control and check the order of data and pro- 
grams to be used. For example, in fire planning, targets will be added 
or deducted, depending upon the fire power required by the S-3. In this 
system the Division S-3 will only consider the targets in range of his 
battalions — the automatic data processing system will automatically 
send to Corps Artillery (higher echelon) those targets which are not in 
range of Division Artillery. 

Integration of Interlocking Functional Areas 

This is the effort that requires coordination among various 
working teams and among the various user groups. The analysis is de- 
veloped similarly to the methods established above, with the limitation 
that most of the efforts resolve themselves to connecting type tasks. 
It should be noted that although functional areas are analyzed as inde- 
pendent work efforts they are, nevertheless, analyzed with respect to 
their dependency and/or alignment with other functional areas. 

In addition, specifications of the subsystem are firmed at an 
early date so that detailed analyses can continue without major dis- 
ruption to the general design of the subsystem. The systems design and 
specification phase is followed by a coordinated testing phase which in- 
cludes: 

1. Establishing test objectives and a method for evaluating 
these tests 

2. Developing an information feedback cycle which could re- 
sult in redesigning, reprograjmming, and retesting portions 
of functional operations 

3. Demonstrating the capability of the ADP subsystem during 
simulative tests and actual equipment tests 

After designing the methodology, an organization for effective- 
ly accomplishing the work effort must then be developed. 
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Organizing for the Effort 

Subsystem la (SS-la) is the. first subsystem of the Tactical 
Automatic Data Processing system to be developed. Its development is 
a complex task invplving the participation of many organizations. 

You. will recall that study groups from the Artillery School 
at Fort Sill, Oklahoma, produced the original ADP studies of specific 
artillery functional areas, and with the enthusiastic cooperation of 
field artillery personnel, SS-la objectives and definitions were de- 
veloped in a very short time period. 

In organizing for the effort, the following factors were con- 
sidered: 

1. SS-1 is but a subsystem of the Tactical Automatic Data 
Processing system. It must fit into the complete ADP 
system, being coordinated with and compatible with other 
subsystems. 

2. The development of SS-1 involves the participation of 
other agencies besides USAEPG and R-W — specifically, 
USCONARC, the Artillery and Missile Center at Fort Sill, 
OCSigO, USASRDL, and contractors to USASRDL. 

¥ell, it does not take much imagination to realize that an integrated 
team approach was required to produce a workable ADP system. The real 
problem was: "What fona can the team take so as to retain its own 
flexibility of operation and still accomplish its tasks without undue 
pressures from outside of its immediate objectives?" This problem, of 
course, is not restricted to military type endeavors; commercial enter- 
prises converting to Electronic Data Processing operations are confronted 
with the same problem. 

Our particular problem was solved by starting at the lowest 
level and forming what we termed a "working team". Each "working team" 
represented an operational function of the f lire .'support subsystem. (See 
Figure 8) , For example, there is a working team for Target Acquisition, 
Fire Planning, Technical Fire Control and one for Communication and 
Equipment, Coordination and interchange of information among ; the four 
teams is accomplished by project coordinators — one located at USAEPG, 
Fort Huachuca, Arizona, and the other in Los Angeles, California. Each 
working team is composed of one artillery project officer, a systems 
analyst, and one programmer. A tactical field test representative is 
assigned to the SS-la project and attends meetings as required, (At 
Fort Huachuca, there is a Field Test Center which will provide the capa- 
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■billty for field testing tactical automatic data processing equipment 
and systems) . 

Each working team has the responsi'bili't^y of accomplishing oh- 
jectives which they have established for themselves . Project coordi- 
nators--one civilian and one military --act as "buffers with respect to 
outside influences which might tend to distract the efforts of each 
working teamo 

Coordination "between USAEPG (Fort Huachuca) and USAAMS (Artillery 
School) is accomplished through artillery project officers and the ar- 
tillery ADP Committee representing members from the various departments 
of the Artillery School. 

As planning problems arise during the development of Fire 
Support Subsystem la^ the USAAMS ADPS Committee effeqts coordination be- 
tween USAAMS and USAEPG in matters of artilleiy policy, doctrine, and 
tactics. To date, this arrangement has met with a great, deal of success. 

The decisions made and the work performed are subject to review 
by the respective military and civilian supervisors to assure their, sound- 
ness, their compatibility with the work on other subsystems, their com- 
patibility with the supporting work on other Army studies, the analysis 
and simulation of individual applications, and to the programming research 
and field experiments generated during the period of subsystem development. 
All decisions and work efforts are reviewed by project management in ac - 
cordance with military command procedure and R-W project management pol- 
icy. Technical decisions proposed by Ramo-Wooldridge are reviewed by the 
ADP Department which, in turn, makes the official. decisions resulting in 
approved plans, designs, equipment procurements, and tests. 

Documentation 

One other important. item remains in the over -all ingredients 
required to accomplish an electronic data processing conversion --this 
ingredient is documentation. 

Documentation in detail is vitally important for the following 
reasons: 

1. Documentation must serve as a clear-cut communication 
vehicle among systems analysts, study project leaders, 
and programmers. This involves standardization of methods 
of operation, procedures and codes. 

2, Documentation must be sufficiently detailed in th^ area 
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of volinnes and frequency of data use. This information 
is required for the projection of equipment needs. 

3- Documentation should provide clear-cut definitions and 
categorizations which -will serve as a "basis in prepar- 
ing work schedules, priority of efforts, and work as- 
signments, both for present and future work efforts. 

h. Detailed documentation will he an aid to the flexibility 
of the! subsystem by providing "elements -of -data" which 
can be grouped and regrouped, depending upon the changes 
in subsystem requirements. 

5. Documentation must be developed in a manner such that 
new personnel coming on the project can, with a minimum 
df effort, understand the work status and direction to 
date . 

The formal documentation for this subsystem consists of: 

1. Objectives and Definitions 

2. Functional Design Charts 

3. Functional Area Analyses 

4. General Logical Flow Chart by Function 

5. Specific Task/Routine Flow Charts 

6. Programming Flow Charts 

7. Integrating of Functional Flow Charts 

All information concerning the subsystem is kept in an operational note- 
book called the "SS-la Docket File". There are 25 "Docket Files" in ex- 
istence. In addition to the formal documents the file includes items as 
changes in working team organization, schedules,- correspondence between 
team members, trip reports, etc. The Docket File is the central re- 
pository for all information and action concerning the subsystem. 



Conclusion 



The certainty is nearly 1.00 (one) that this methodology cannot 
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"be used intact for another data processing project or system. Each 
project or system has its own peculiarities^ its own distinctive milieu^ 
and its own conditions and objectives --known and unknown. However, 
whether the project is military or commercial, it can still use much 
of the methods philosophy described in this paper. 
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PAGE I OF 7 



AREA 27 OF 41 



STUDY OR AREA TITLE TARGET DATA AND UNIT ANALYSIS 



NAME OF INPUT 



FIRE PLANNING CRITERIA 



FLOW CHART REFERENCE 



DC 940 



SEQUENCE NO. 942-3 



PREPARED BY ^L MORAVEC 



°'^'^^ 9 FEB. I960 



INPUT RELATED TO TARGET DATA LIST FILE AND UNIT LOCATION FILE 



SOURCE S-3 DETERMINES WHICH FIRE PLANNING CRITERIA VALUES OR FACTORS WILL BE USED 
FREQUENCY (IMMEDIATE, BATCH, OTHER) PRIOR TO ORDERING OF TGTS - TWICE FOR SSIa 



METHOD OF TRANSMISSION PRE - PROGRAMMED ON PAPER TAPE 



PHYSICAL FORMAT SEE ATTACHED SHEETS 



SPECIAL CODING REQUIRED NONE 



INPUT LOCATION (FIELD ARMY, CORPS, DIV., OTHER) DIVARTY FDC 8ASICPAC 



REF 
NO. 



LINE 
NO. 



DESCRIPTION 



FIRE PLANNING CRITERIA 

1. CALIBER TO TYPE TGTS (TARGET/ 
WEAPON PREFERENCE CHART) 

2. PRIORITY TO TYPE TGTS 

3. STANDARD VOLLEYS PER UNIT 

4. INTENSITY DESIRED (FRACTIONAL 
DAMAGE DESIRED) 

5. EFFECTIVENESS ANALYSIS COMPUTATION 
PARAMETERS (TGT/WEAPONS LETHAL 
EFFECTS) 

6. AMMO REQUIREMENTS 

7 REPEAT REQUIREMENTS 

8. EFFECTS SAFETY LINE 
(NO FIRE LINE ADJUST) 



LINE TOTAL 



TOTAL NO. OF INPUTS (DOCUMENTS PER 24 HR. PERIOD) 
ADDITIONAL TIMING OR EQUIPMENT REQUIREMENTS 



NO. OF 
CHARACTERS 

ESTIMATED 
averageImaximum 



40 

30 
10 
12 

50 

25 
10 
20 
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50 
15 
16 

70 

30 
12 
30 
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EXAMPLE 



FILE CONTENTS SHEET SSIa 



E SEQUENCE page 5 of 7 

AREA 31 OF 41 



STUDY OR AREA TITLE 



TARGET DATA AND UNIT ANALYSIS 



NAME OF FILE 



FIRE PLANNING CRITERIA AND COMPUTATIONAL PARAMETERS 



FLOW CHART REFERENCE 



DC 940 



SEQUENCE NO. 942-3 



PREPARED BY 



AL MORAVEC 



9 FEB. I960 



TYPE OF FILE 



PHYSICAL CHARACTERISTICS OF FILE 



BASICPAC MEMORY 



PURPOSE OF FILE COMPUTATION OF TARGET/ UNIT EFFECTIVENESS DATA 



FILE LOCATION (FIELD ARMY, CORPS, DIV., OTHER) BASICPAC DIVARTY 



FREQUENCY OF REFERENCE 



(24 HR. PERIODS) 



DEGREE OF ACCESSIBILITY AS REQUIRED 



NEED FOR DUPLICATE STORAGE 



NONE 



MEANS OF (INPUT - OUTPUT) TO FILE MAG TAPE (OR COMPUTER MEMORY) 



COMPUTER PROGRAM REQUIREMENTS NONE 



REF 
NO. 



RECORD 
NO. 



DESCRIPTION 



I. TARGET DATA FILES 

2. FIRING UNIT DATA FILES 

3. FIRE PLANNING CRITERIA AND 
COMPUTATION PARAMETER FILES. 



RECORD TOTAL 



NO. OF 
CHARACTERS 

ESTIMATED 

AV MAX 



2800 

2400 

150 



3000 

2800 

300 



TOTAL 5350 6100 SECURITY OF FILE 



FILES 




BASICPAC 
MEMORY 



ADDITIONAL TIMING OR EQUIPMENT REQUIREMENTS 



ADPS FORM 200 (ARTILLERY) APRIL 1989 



FIGURE 6 



EXAMPLE 



E SEQUENCE 



OUTPUT DATA SHEET SSIa 



PAGE 6 OF 7 

AREA 32 OF 41 



STUDY OR AREA TITLE 



TARGET DATA AND UNIT ANALYSIS 



NAME OF OUTPUT 



1. TARGETS THAT CAN T BE HIT EFFECTIVELY 

2. TARGET/UNIT EFFECTIVENESS ASSIGNMENT PLAN 



FLOW CHART REFERENCE DC 940 



SEQUENCE NO. 941-2,3,4 



PREPARED BY 



AL MORAVEC 



9 FEB. I960 



SOURCE (TYPE FILE OR TAPE) TGT. DATA FILES, COMPUTER MEMORY FIRING UNIT FILES, FIRE PLANNING, 

SOURCE (TYPE FILE OR TAPE) CRITERIA FILE 



METHOD OF TRANSMISSION 



BASICPAC COMPUTER 



PHYSICAL FORMAT (REPORT, DISPLAY, OVERLAY, ETC.) PRINTOUT HARD COPY " SEE ATTACHED SHEET 



OUTPUT LOCATION (FIELD ARMY, CORPS, DIV., OTHER) DIVARTYFDC BASICPAC 



NO. OF COPIES IF REPORT 



S-3, S-2 DIVARTY 



SPECIAL PROGRAMMING REQUIRED 



NONE 



REPRODUCTION REQUIREMENTS 



1. TGTS, UNITS CAN'T HIT 

2. TGT/UNIT EFFECTIVENESS ASSIGNMENT PLAN 



DISSEMINATION NEEDS 



TO S-3 AND S-2 OF DIVARTY 



REF. 
NO. 



LINE 
NO. 



DESCRIPTION 



1. TARGETS UNITS CAN HIT 

2. UNITS CAN HIT TARGETS 

3. TARGETS THAT CAN'T BE HIT 
EFFECTIVELY (HARD COPY OUTPUT) 

4. TARGET/UNIT EFFECTIVENESS 
ASSIGNMENT PLAN (HARD COPY) 



NOTE 



AMMO TYPE IS HE, FUZE IS FUZE QUICK, 
CHARGE AND NO. OF ROUNDS ARE 
DETERMINED AFTER TARGET/UNIT 
EFFECTIVENESS ASSIGNMENTS. 



LINE TOTAL 



TOTAL NO. OF OUTPUTS (REPORTS OR DISPLAYS PER 24 HR. PERIOD) 
ADDITIONAL TIMING OR EQUIPMENT REQUIREMENTS 



NO. OF CHARACTERS 



AVERAGE MAXIMUM 



3000 
3000 

700 
1000 



6700 



4000 

4000 

900 

1500 



8900 



ADPS FORM 300 (ARTILLERY) APRIL ISSS 



FIGURE 7 



BASICPAC 
MEMORY 



COMM. 
ASSY 



( PRINTER ) 



S-2 



S-3 

TARGETS 
UNITS can't 
HIT 



S-2 



S-3 

TGT/UNIT 

EFFECTIVENESS 

ASSIGNMENT 

PLAN 



SECURITY OF OUTPUT 



ORGANIZATION FOR SSIa EFFORT 

FUNCTIONAL AREA FIRE PLANNING 

WORKING TEAM 

1. SYSTEM ANALYSIS R-W AND USAEPG 

2. PROGRAMMING R-W AND USAEPG 

3. FIELD TEST R-W AND USAEPG 

4. USER COORDINATION TACTICS AND COMBINED 

ARMS DEPT. 
(ARTILLERY SCHOOL) 

GENERAL COORDINATION 

USAEPG - SUBSYSTEM COORDINATOR 

ADP DEPARTMENT 

USAAMS - CHAIRMAN 

ARTILLERY SCHOOL ADPS 
COMMITTEE 

FIGURE 8 



